Bad data: No entry in BSD for baseline set.

I have a script that gets kicked off late night that opens just about every module in my project (in the mid 100s) and dumps data to a text file. Sometime during its run, it craps out this message:

DOORS: ASSERTION FAILED, Line 2609, .\Document.cpp: !NLS_("Bad data: No entry in BSD for baseline set.")

It doesn't stop, but it does pause for user input in its DOS console, which pretty much kills any benefit of running it at night automatically.

Has anyone seen this error before?

One theory I have: I use baseline sets, but via a script that users run. That script creates a BSD, baselines all the modules in the open set, closes the set, and then deletes the BSD.

Is that bad? I didn't want those one-off BSDs cluttering up the folders and everything seemed to work fine after I deleted them. Should I have left those old one-off BSDs in the folder?

Thanks.

SystemAdmin - Mon Mar 21 18:51:58 EDT 2011

Re: Bad data: No entry in BSD for baseline set.
Mathias Mamsch - Tue Mar 22 05:43:42 EDT 2011

Hmm that looks more like a corrupt data error ... Is it possible that the script which made the baselines and the Baseline Set got kicked off during its operation and left one baseline Set corrupted? The next time that you see this message, you should abort the script and see from the output at which module it stopped. Maybe you can find any indication for the error message. Does your module-dumping-script open any baselines? Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Bad data: No entry in BSD for baseline set.
llandale - Tue Mar 22 12:06:20 EDT 2011

Don't know.

But I've had a few of these massive scripts over time and found its important to know exactly where the script is when it aborts. print statements work rather well since they force the DOS window to stay open even after DOORS exists (or aborts), allowing you to see them. Also, I found that writing to a huge report file may better be done by frequently closing the output file and appending it right away. Thus, if DOORS aborts at least you get data up to that point. While closing and appending can be done for every output line, perhaps it could be done after you announce the opening of a module; thus if DOORS aborts you know where the script was.

Once you find the offending module you should play with it interactively, such as archiving it, to see if its corrupted or whatever.

Also, these massive scripts will require you to frequently close residually open modules often. Perhaps every time you open a folder to find a module, you should close all modules:
for mod in database do
{ close(mod, false)
}

Louie

Re: Bad data: No entry in BSD for baseline set.
SystemAdmin - Wed Mar 23 11:58:43 EDT 2011

I narrowed the error down to a particular module. I can open the module and its baselines without incident in the GUI. I cut/pasted the exact function used in the nightly script that opens modules into the interactive DXL editor and ran it, but did not get the error. So it feels like some diff between interactive and batch mode. :(

I do not open baselines during the nightly script, only current. There are no BSD in the folder, since my baseline set script deletes the BSD after performing the baseline set; but why would this be an issue for one folder out of fifty?

Thanks.

Re: Bad data: No entry in BSD for baseline set.
llandale - Wed Mar 23 14:55:49 EDT 2011

SystemAdmin - Wed Mar 23 11:58:43 EDT 2011
I narrowed the error down to a particular module. I can open the module and its baselines without incident in the GUI. I cut/pasted the exact function used in the nightly script that opens modules into the interactive DXL editor and ran it, but did not get the error. So it feels like some diff between interactive and batch mode. :(

I do not open baselines during the nightly script, only current. There are no BSD in the folder, since my baseline set script deletes the BSD after performing the baseline set; but why would this be an issue for one folder out of fifty?

Thanks.

Don't know.

I think you should run the entire script interactively, not just the part you believe is getting this error. Perhaps start DOORS, initiate the script, and go home. I think you could simulate this by changing your batcn command, replacing the "-b" switch with "-D" to run it, which runs interactively and keeps it open.

I'd be tempted to dump all your Baseline Set Definitions.

I wonder about your original posted error, I can say I've never seen a DOORS error that actually tells you ..err.. shows you the line of code giving an error, <!NLS_("bla bla bla")> IIRC. Is that the error, or is that the line of code you know to be producing the error? The "!" looks suspicious, since NLS_ returns a string.

I wonder if you could keep going after this error using a script that looks like this:

void ack       (string Message)    {  print Message "\n"}
void acknowlege(string Message) {  ack(Message)}
void warningBox(string Message) {  ack(Message)}
void errorBox  (string Message) {  ack(Message)}
#include <my batch script>

Cleverly overriding the standard functions that pause.

Louie

Re: Bad data: No entry in BSD for baseline set.
SystemAdmin - Thu Mar 31 10:37:02 EDT 2011

Hey kids, I just remembered something that might explain why this error is happening:

That script I mentioned, the one that makes baseline sets, was used on the offending module's part folder at least once. Sometime after using it, the owners of this part decided to do some major redecorating. They had me remove one of their modules (which would have been included in at least one baseline set) and make a copy of a second module that was then reworked into something like the one removed. So this copied/reworked module now has the same name as the one removed. I suspect something is complaining about an aspect or artifact of the removal/copy operations in relation to a baseline set. If whatever is complaining is using the uniqueID of modules, this shouldn't happen, right? But if it's using fullName of modules, then I can see how this error might occur.

Aside [1]: Does anyone know if IBM support people troll these forums?

Aside [2]: I stopped running the script automatically at night. I broke it up into pieces and now someone runs it in the morning. It wasn't just this error that made me finally decide to stop, merely one straw on the heap on the camel's back.

Thanks again for your interest and suggestions.